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Abstract. An established trend in software engineering insists on using 
components (sometimes also called services or packages) to encapsulate a 
set of related functionalities or data. By defining interfaces specifying what 
functionalities they provide or use, components can be combined with 
others to form more complex components. In this way, IT systems can 
be designed by mostly re-using existing components and developing new 
ones to provide new functionalities. In this paper, we introduce a notion 
of component and a combination mechanism for an important class of 
software artifacts, called security-sensitive workflows. These are business 
processes in which execution constraints on the tasks are complemented 
with authorization constraints (e.g., Separation of Duty) and authorization 
policies (constraining which users can execute which tasks). We show 
how well-known workflow execution patterns can be simulated by our 
combination mechanism and how authorization constraints can also be 
imposed across components. Then, we demonstrate the usefulness of our 
notion of component by showing (i) the scalability of a technique for the 
synthesis of run-time monitors for security-sensitive workflows and (ii) 
the design of a plug-in for the re-use of workflows and related run-time 
monitors inside an editor for security-sensitive workflows. 


1 Introduction 

Nowadays, business processes constantly strive to adapt to rapidly evolving 
markets under continuous pressure of regulatory and technological changes. 
In this respect, the most frequent problem faced by companies is the lack of 
automation when trying to incorporate new business requirements into existing 
processes. A traditional approach to business process modeling frequently results 
in large models that are difficult to change and maintain. This makes it critical 
that business process models be modular and flexible, not only for increased 
modeling agility at design-time but also for greater robustness and flexibility 
of enacting processes at run-time (see, e.g., m for a discussion about this and 
related problems). 

The situation is further complicated when considering the class of security- 
sensitive workflows [I], i.e. when tasks in processes are executed under the 
responsibility of humans or software agents acting on their behalf. This means 
that, besides the usual execution constraints (specified by causal relations among 
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tasks), security-sensitive workflows add authorization policies and constraints, i.e. 
under which conditions users can execute tasks. Authorization policies are usually 
specified by using some variant of the Role Based Access Control (RBAC) model, 
see, e.g., 1 20] , while authorization constraints restrict which users can execute 
some set of tasks in a given workflow instance; an example is the Separation of 
Duties (SoD) constraint requiring two tasks to be executed by distinct users. Since 
authorization policies and constraints may prevent the successful termination of 
the workflow (i.e. not all tasks can be executed), it is crucial to be able to solve 
at design-time, the Workflow Satisfiability Problem (WSP) [5|, i.e. establishing 
if all tasks in the workflow can be executed satisfying the authorization policy 
without violating any authorization constraint, and at run-time, a variant of the 
WSP requiring the synthesis of a monitor capable of granting the request of a 
user to execute a task if this does not prevent the successful termination of the 
workflow instance (see, e.g., EH). The combination of the need for modularity 
and flexibility with that for developing efficient techniques to solve the WSP and 
its run-time variant gives rise to new fundamental questions, such as 

Ql: how can we specify security-sensitive workflow components, i.e. business 
processes equipped with interfaces defining their inputs and outputs together 
with their dependencies (a component declares the services it provides and 
those that it depends upon)? 

Q2: how can we “glue together” components into a more complex one that can 
again be combined with others if necessary? 

Q3: how can we solve the WSP and synthesize run-time monitors for security- 
sensitive workflow components that can be modularly re-used to solve the 
WSP and synthesize a run-time monitor for their combination? 

In this paper, we provide answers to the three questions above by making the 
following contributions: 

Al: we introduce the notion of security-sensitive workflow component (Section^ 
as a symbolic transition system extended with a suitable notion of interface, 
A2: we define how components can be “glued together” (Section^ by specifying 
how execution and authorization constraints of components become related, 
A3: we describe how run-time monitors solving the WSP of security-sensitive 
workflow components can be modularly reused (Section[4]) to build one solving 
the WSP of their combination. 

We show the adequacy of Al and A2 by showing how a typical security-sensitive 
workflow can be specified as a composition of components (Section [2]). (A2 is 
further elaborated in Appendix [A] by demonstrating how the main composition 
patterns for workflows, such as those in m, can be simulated by our notion of 
gluing.) 

Another contribution of the paper is an investigation of how our proposal 
can be exploited in an industrial setting (Section [4]) . In particular, we consider 
two main issues. First, we show how splitting into several modules large security- 
sensitive workflows, by using Al and A2, allows for the synthesis of run-time 




Fig. 1. TRW (left) and MDW (right) in extended BPM notation 


monitors to scale up, by using A3. Second, we sketch the architecture of a 
tool for the creation of security-sensitive workflows which maintains a library of 
components together with their run-time monitors. This holds the promise to 
help workflow designers in their quest for adapting processes to rapidly evolving 
requirements. 

2 Security-sensitive Workflow Components 

We introduce a refinement of the notion of symbolic transition system in [3] which, 
associated to a suitable notion of interface, constitutes a (symbolic) security- 
sensitive component. We motivate the utility of this notion by means of an 
example. 

Example 1. Figure [l] shows two workflows in BPM Notation (BPMN) |T5). Each 
workflow contains two circles, the one on the left represents the start event 
(triggering the execution of the workflow), whereas that on the right the end 
event (terminating the execution of the workflow), tasks are depicted by labeled 
boxes, the constraints on the execution of tasks are shown as solid arrows (for 
sequence flows) and diamonds labeled by + (for parallel flows), the fact that a 
task must be executed under the responsibility of a user is indicated by the man 
icon inside a box, and the SoD constraints as dashed lines labeled by 7 C 

The workflow on the left is the Trip Request Workflow (TRW) whose goal is 
that of requesting trips for employees in an organization. It is composed of five 
tasks: Request (£1), Car rental (£2), Hotel booking (£3), Flight reservation (£4), 
and Validation (£5). Five Separation of Duty (SoD) constraints must be enforced, 
i.e. the tasks in the pairs (£1,£2), (41,£4), (£2,£3), (£2,£5), and (£3,£5) must be 
executed by distinct users in any sequence of task executions of the TRW. 

The workflow on the right is the Moderate Discussion Workflow (MDW) 
whose goal is to organize a discussion and voting process in an organization. It is 
composed of four tasks: Request (£1), Moderate Conference Call (£7), Moderate e- 
mail Discussion (£7), and Validation (£5). Four SoD constraints must be enforced: 
(£1,£ 6 ), (£ 6 ,£5), (£ 6 ,£7), and (£7,£5). 

In both workflows, each task is executed under the responsibility of a user 
who has the right to execute it according to some authorization policy, which- for 
the sake of brevity—we leave unspecified. 

Notice that tasks £1 and £5 in Figure[l]are the same in both TRW and MDW. 
The goal of this paper is to develop a notion of security-sensitive component 



















such that tasks tl and t5 can be modularly reused in the specifications of both 
workflows so that only the specification of the parallel execution of tasks f2, f3, 
and tA for the TRW and t6 and tl for the MDW must be developed from scratch 
in the two cases. Additionally, we want that run-time monitors for the various 
components can also be modularly reused. 

Indeed, the simplicity of the TRW and MDW spoils the advantages of a 
modular approach; the small dimension of the workflows allows us to keep the 
paper to a reasonable size. However, for large workflows—as we will see below in 
Section [4]— the advantages are substantial. To give an intuition of this, imagine to 
replace the tasks reused in both workflows, i.e. tl and f5, with complex workflows: 
reusing their specifications and being able to synthesize run-time monitors for 
them, that can be used for larger workflows in which they are plugged, becomes 
much more interesting. □ 

A (symbolic) security-sensitive component is a pair (S', Int) where S is a (symbolic) 
security-sensitive transition system and Int is its interface. 

Security-sensitive transition system. Since the semantics of BPMN can be 
given by means of (extensions of) Petri nets (see, e.g., [Tj3]) and the latter can be 
represented as symbolic state transition systems (see, e.g., [ W),s is the symbolic 
transition system that can be associated to security sensitive workflows specified 
in BPMN as those in Figure [l] A (symbolic) security-sensitive transition system 
S is a tuple of the form ((P, D , A, H , C), Tr, B) where PUDUAUffUC are the 
state variables, Tr is a set of transitions, and B is a set of constraints on the state 
variables in C. The finite set P contains Boolean variables representing the places 
of the Petri net associated to a BPMN specification of the security-sensitive 
workflow and D is a finite set of Boolean variables representing the fact that a 
task has been executed or not; P Li D are called execution constraint variables. 
The finite set A contains interface predicates to the authorization policy, H is a 
set of predicates recording which users have executed which tasks, and C is a 
set of interface predicates to the authorization constraints; AU H L) C are called 
authorization constraint variables. The set Tr contains the transitions (or events ) 
of the form 

t(u) : en EC (P, D) A en Aath (A,C) act EC (P, D)\\act Auth (H) (1) 

where t is the name of a task taken from a finite set, u is a variable ranging over a 
set U of users, en E c(P , D) is a predicate on P\JD (called the enabling condition for 
the execution constraint ), eriAuth(A C) is a predicate on {i>(u)|t; £ AuC} (called 
the enabling condition for the authorization constraint ), act E c(P, D) contains 
parallel assignments of the form v := b where v £ P U D and b is a Boolean value 
(called the update of the execution constraint of the security sensitive workflow), 
and ocfAuth(P) contains parallel assignments of the form v(u) := b where v £ H 
and b is a Boolean value (called the update of the authorization history of the 
security sensitive workflow) Q Finally, the finite set B contains always constraints 

The assignment v(u) := b leaves unchanged the value returned by v for any v! distinct 
from u. In other words, after the assignment, the value of v can be expressed as 
follows: A x.if x = u then b else v(x). 



of the form 


\/u.v(u) <t=> hst, ( 2 ) 

where it is a variable ranging over users, v is a variable in C , and hst is a Boolean 
combination of atoms of the form w(u) with w £ H. 

Interface of a security-sensitive component. The interface Int of a symbolic 
security-sensitive component ( S,Int ) is a tuple of the form (A,P l ,P°, H°,C l ) 
where 

— P l C P and each p l £ P l is such that p l := T does not occur in the parallel 
assignments of an event of the form 0 in Tr, 

— P° C P and each p° £ P° is such that p° := T occurs in the parallel 
assignments of an event of the form 0 in Tr whereas p° := F does not, 

— H° C H, C l C C, and 

— only the variables in (C\ C l ) U H° can occur in a symbolic always constraint 
of B. 

When P l , P°, H°, and C l are all empty, the component ( S,Int ) can only be 
interfaced with an authorization policy via the interface variables in A. The 
state variables in D are only used internally, to indicate that a task has been 
or has not been executed; thus, none of them is exposed in the interface Int. 
The variables in P, H, and C are local to S but some of them can be exposed 
in the interface in order to enable the combination of S with other components 
in a way which will be described below (Section [3]). The super-scripts i and o 
stand for input and output, respectively. The requirement that variables in P l 
are not assigned the value T(rue) by any transition of the component allows their 
values to be determined by those in another component. Dually, the requirement 
that variables in P° can only be assigned the value T(rue) by any transition 
of the component allows them to determine the values of variables in another 
component. Similarly to the values of the variables in P l , those of the variables 
in C l are fixed when combining the module with another; this is the reason for 
which only the variables in C\C l can occur in the always constraints of the 
component. 

Example 2. We now illustrate the notion of security-sensitive component by 
considering the workflows in Figure |T| As said in Example [l] we want to reuse 
tasks tl and f5 in both TRW and MDW. For this, we split the specification of each 
workflow in four components C\, C 234 , C 67 , and C 5 as shown in Figure [2j where 
the sequential composition of C\, C 234 , and C 5 yields TRW and that of Ci, Cqt, 
and C 5 gives MDW. The figure shows the extended Petri nets representing the 
four components and how they are connected: circles represent places, rectangles 
with a man icon transitions to be executed under the responsibility of users, 
rectangles without the icon transitions not needing human intervention, (black) 
dashed lines represent SoD constraints between tasks belonging to the same 
component, (gray) dashed lines SoD constraints between tasks belonging to 
distinct components, (black) solid arrows the control flow in the same component, 



Fig. 2. TRW and MDW as combinations of security-sensitive components 


and (gray) dashed arrows the control flow between two components. Note that 
the control flow between two components is outside of the semantics of extended 
Petri nets. For example, a token in place pO of C\ goes to pi of C\ after the 
execution of 11 and, at the same time a token is put in place pi of C234 because 
of the (gray) dashed arrow from pi in C\ to pO in C234 representing an inter 
execution constraint. When the token is in pO, the system executes the split 
transition s in C234 that removes the token from pO and puts one in pi, p 2 , and 
p3 so that t2, t3, and t4 in C234 become enabled. Notice that the execution of t2 
is constrained by a SoD constraint from task tl in component C\ (dashed arrow 
between tl in C\ and t2 in C234): this means that the user who has executed tl 
in C 1 cannot execute also t2 in C234. 

We now show how to formalize the components depicted in Figure[2]by defining 
C\ = {Si, Inti), C 5 = ( Ss,Int 5 ), C234 = (S234, Cnt 234)1 and ^67 = (<$67) Int&j) 
where S y = {{P y , D y , A y , H y ,C y ), Tr y ,B y ), and Int y = {A y ,P^,P°,H°,C l y ) for 
y = 1,5, 234,67. For components C1 and C5, we set 

Py ■= {pO y >pl y } Dy := {^ty} Ay '.= {a(y} H y .— {hty} Cy •= { c ty} D y .— 0 

PI := {pOy} P° := {ply} H° := { h ty } . 
for y = 1,5, and take 

Tr i := {tl(u) : pOi A ->d tx A a n (u) pOi,pli,d tl ,h tl (u) := F,T,T,T} 

Tr 5 := {t5(u) : p0 5 A ~^d t5 A a t5 (u) A c l t5 {u) -t p0 5 ,pl 5 , d t5 , h t5 (u) := F, T,T,T] 
C{ := 0 Cl := {ct 5 } . 

According to the transition in Tr\, task tl is enabled when there is a token 
in place pOi (place pO of component Ci in Figure [2]), tl has not been already 
executed {~<dti) and there exists a user u capable of executing tl (ati(u)). The 
effect of executing such a transition is to move the token from pOi to pli (places 



























pO and pi of component C\ in Figure [2j respectively), set dti to true meaning 
that tl has been executed, and recording that tl has been executed by u. The 
interface of each component is the following: pO y is the input place, pl y is the 
output place, and the history variable ht y can be used to constrain the execution 
of tasks in other components (for instance of 72 in the TRW as tl and t2 are 
involved in a SoD, shown by the gray dashed line between the two tasks in 
Figure [2]). Notice that the execution of task tl cannot be constrained by the 
execution of tasks in other components (thus C\ := 0) since tl is always executed 
before all other tasks and cannot possibly be influenced by their execution. The 
definition of the transition in Tr§ is similar to that in Tri except for the fact 
that the execution of task 75 can be constrained by the execution of tasks in 
other components (thus Cl := {c) 5 }) since 75 is always executed after all other 
tasks and can be influenced by their execution. In particular, c l t5 will be defined 
so as to satisfy the SoD constraints between 75 and t2 or 73 for TRW and 76 or 
t7 for MDW. For component C234, we set 


:= F, T, T, T, T 1 


#234 := {py 234 \y = 0,..., 7} £>234 := {^ 234 , J 234 , d ty \y = 2, 3,4} 

^234 : = \ a ty\y = 2, 3,4} #234 := {Wy\y = 2,3,4} C234 := {c t 2, c t 3, c\y\v = 2, 3,4} 
#234 := {iu.c t2 {u) -ih t3 (u),\/u.c t3 (u) ->/i t 2 (u)} 

S 234 : 7*0234 A -1 d s —> p0234,pl234,p2234,p3234 
t2(u) : pi 234 A -idt 2 A a t2 (u) A c t2 (u) A cj 2 (u) 

—t pl 23 4, p4234, dt2, ht 2 {u ) := F, T, T, T 
t3(u) : p2 234 A -*dt 3 A a t3 (u) A c t3 (u) A c l t3 (u ) 

-t p 2 23 4 ,p 5 2 34 , dt 3 , h t3 (u) := F,T,T,T 
tA(u) : p3 2 34 A -'dti A a f4 («) A cj 4 (u) 

-t p 3 23 4 ,p 6 2 34 , dti, h t i{u) := F,T,T,T 
J 234 : p4 2 .34 A p5 2 .34 A p6 2 .34 A ~^d 


Tr 234 := < 


: p4 234 A p5 23 4 A p6 23 4 A ^ 

P4 23 4,p5234,p6234,p7234, d 


3 234 


:=RRRT,T 


1*234 ■— {PO234} P 2l 34 {7*7234} #234 {^*2,^*3} C234 { c t 2 , c t . 4 :}- 


Transitions S 234 and J 234 (corresponding to the rectangles labeled s and j of 
component C 234 in Figure [ 2 ]) model the parallel composition of tasks 72, 73, and 
74 in TRW and MDW (cf. the parallel flows depicted as diamonds labeled with 
+ in Figure [T]). Since no human intervention is needed, the enabling conditions 
for the authorization constraint of both transitions are omitted. Tasks 72 and 
73 are involved in a SoD constraint (cf. the dashed lines labeled by ^ between 
72 and 73 in Figure [ 2 ]). For this reason, their enabling conditions contain Ct 2 ( u ) 
and Ct 3 ( u ) which are defined in #234 so as to prevent the execution of 72 and 73 
by the same users: to execute 73 (72, resp.), user u must be such that ~^ h t 2 { u ) 
( _l ^-t3 ( u ), resp.), i.e. u should have not executed 72 (73, resp.). Transitions 72, 73, 
and 74 in Tr 234 have enabling conditions that contain c \ 2 { u ), c ^ u ), and cj 4 (it) 
which will be defined so as to satisfy the SoD constraints in which the tasks 
are involved (cf. the gray dashed lines across the rectangles in Figure [ 2 ]). The 






definition of component Cq 7 is quite similar (albeit simpler) to that of C234: 


Pg 7 ■= {PV 67 \y = 0, ...,5} D 67 := {s 67 J 67 ,dty\y = 6 , 7} A 67 := {a ty \y = 6,7} 
H g7 ■.= {h ty \y = 6,7} C 67 := {c tv ,c l ty \y = 6,7} 

B 6 7 := {Vm.c 46 (m) <S=> -^h t7 (u),\/u.c t7 (u) O ~^h t6 (u)} 

S67 ■ p0 6 7 A ~^d s -» p0 6 7,pl67,p2 67 , d S67 := F,T,T,T 

t6(u) : pl e7 A - 1 dte A a t 6 (u) A c 46 (u) A cj 6 (u) 

T J pl67,p3 6 7,d t 6,h t6 (u) \= F,T,T,T > 

67 ' t7(u) : p2 67 A -id t7 A a t7 (u) A c t 7 (u) A cj 7 (u) ( 

~t p2 67 ,p4 67 , d t7 , h t7 (u) := F,T,T,T 
367 ■ p3 67 A p4 67 A -idj ->■ p3 67 ,p4 67 ,p5 67 , d j67 := F, F, T, T 

Ph ■= {P0 67 } Pi 7 ~ {P5 67 } Bh ■= {h t 6,h t7 } Q 7 := {c| 6 }. 

Section [3] below explains how components Ci, C 234 , C 6 7 , and C 5 can be “glued 
together” to build TRW and MDW. □ 

Semantics of a security-sensitive component. The notion of symbolic 
security-sensitive transition system introduced here is equivalent to that in [3]; 
the only difference being the presence of the authorization constraint variables 
in C together with the always constraints in B. It is easy to see that, given 
a transition system ((P, D, A, H,C), Tr,B), it is always possible to eliminate 
the variables in C occurring in B from the conditions of transitions in Tr by 
using ([ 2 ]): it is sufficient to replace each occurrence of v(u) with hst. Let [[tr]]s 
denote the transition obtained from tr by exhaustively replacing the variables 
in C that also occur in B as explained above. Since no variable in C may occur 
in the update of a transition and in the enabling condition for the execution 
constraint of a transition, by abuse of notation, we apply the operator [[-]]b to 
the enabling condition for the authorization constraint of tr. The substitution 
process eventually terminates since in hst there is no occurrence of variables in 
the finite set C, only the variables in H may occur. The possibility of eliminating 
the variables in C allows us to give the semantics of the class of (symbolic) 
security-sensitive transition systems considered here by using the notion of weak¬ 
est liberal precondition (wlp) [ 7 ] as done in [ 3 ]. The intuition is that computing 
a wlp with respect to the transitions in Tr and the always constraints in B is 
equivalent to computing that with respect to [[XrJJ/j. Formally, we define 

wlp(7V,P, K) := \/ (ctiec A {[en Au th]]s A K[act E c 11 act Au th]) (3) 

Tr 

where B is a set of always constraints, tr is of the form (JT|) , PT is a predicate over 
P L) D U AU C, and K[act E c\\ act Auth] denotes the predicate obtained from K 
by substituting 

— each variable v £ P U D with the value b when the assignment v := b is in 
ac<EC an d 

— each variable v € H with Xx.if x = u then b else v(x) when v(x) := b is in 
act Auth for b a Boolean value. 






It is easy to show that wlp( Tr, B, K ) is \/ treTr \N\p(tr,B,K). When Tr is a 
singleton containing one symbolic transition tr, we write wlp (tr,B,I\) instead of 
wlp {{tr},B,K). 

A symbolic behavior of a security-sensitive transition system S = ((P, D, A, H, 
C ), Tr, B) is a sequence of the form K 0 A'| —V • • • tr A-^ x n where K, is a 
predicate over PUdUiUC and tr* is a symbolic transition such that K. L is 
logically equivalent to wlp(frj, B, Ki + \) for i = 0, ...,n — 1. The semantics of the 
security-sensitive transition system S is the set of all possible symbolic behaviors. 
The semantics of a security-sensitive component ( S, Int) is the set of all possible 
symbolic behaviors of the security-sensitive transition system S. 

Example 3 . We consider component C5 (cf. Example [ 2 ]) and compute the wlp 
with respect to t 5 (u) (in the set Tr 5 of transitions) for the following predicate 
-up0 5 Apl 5 A d t 5 characterizing the set of final states of C 5 , i.e. those states in 
which task Z5 has been executed and there is just one token in place pl. 5 . By 
using definition |3| above, we obtain pOs A ~^dt5 A a t : 3 (u) A c\ 5 {u), which identifies 
those states in which there is a token in place pOi, task tl has not yet been 
executed, and user u has the right to execute tl and authorization constraints 
imposed by other components are satisfied (e.g., the SoD constraint between Z5 
and t 2 in C234 for the TRW). □ 

3 Gluing together Security-Sensitive Components 

We now show how components can be combined together in order to build other, 
more complex, components. For Z = 1,2, let (Si, Inti) be a symbolic security- 
sensitive component where Inti = (A, P), P°, H", Cj) and Si = ((Pi, Di, Ai, Hi, 
Ci), Tri,Bi) is such that Pi and P2, D\ and D 2 , A± and A 2 , Hi and H 2 , C\ 
and C 2 are pairwise disjoint sets. Furthermore, let G = Gec U GAuth be a set of 
gluing assertions over Inti and Int 2 , where 

— Gec is a set of formulae of the form p l p° for p l £ P £ and p° £ P°, called 
inter execution constraints, and 

— GAuth is a set of always constraints in which only the variables in G£ U H° 
may occur, 

for k,j = 1,2 and k ^ j. Intuitively, the gluing assertions in G specify inter 
component constraints; those in Gec how the control flow is passed from one 
component to another whereas those in G'Auth authorization constraints across 
components, i.e. how the fact that a task in a component is executed by a certain 
user constrains the execution of a task in another component by a sub-set of the 
users entitled to do so. 

The symbolic security-sensitive component (S, Int) obtained by gluing (Si, Inti) 
and (S 2 , Int 2 ) together with G, in symbols (S, Int) = (Si, Inti) ©G ($ 2 , ^2)1 is 
defined as S = ((P, D, A, H, C), Tr, B) and Int = (A, P l , P°, H°, G l ), where 


- P = Pi U P 2 , D = Di U D 2 , A = Ai U A 2 , H = Hi U H 2 , C = Gi U C 2 , 


— Tr := [7Vi] Gec U [Tr 2 ] GEC where [2 Vj]g ec := {[^]ge C I^ e Tr o} and 
[t r j]G EC is obtained from trj by adding the assignment p l := b if p l is in P?, 
there exists an inter execution constraint of the form p l ■*=> p° in Gec, P° is 
in , and p° := b is among the parallel assignments of tr'j ; otherwise, trj is 
returned unchanged, for j, k = 1,2 and j 7 ^ k, 

— B = Bi U B 2 U GAuth, 

— P l = {p £ (Pl U Pl ) \p does not occur in Gec}, 

— P° = {p € (P° UP 2 °)|p does not occur in Gec}, 

— H° = HI U F 2 °, and 

— C l = {c G (GJ U G 2 )|c does not occur in GAuth}- 

The definition is well formed since S is obviously a security-sensitive transition 
system and Int satisfies all the structural constraints at page [5] 

Example 4 - Let us consider components C\ and C 2 34 of Example [ 2 j We glue 
them together by using the following set G = Gec U GAuth of gluing assertions 
where G E c := -fall •<=> p0 234 } and G Au th := {iu.c\ 2 (u) 4 => ~>h tl (u), Vu.c| 4 fa) 4 => 
-<hti(u)}. The inter execution constraint in Gec corresponds to the dashed arrow 
connecting pl in component C\ fall) to pO in component C234 (p0 23 4) in Figure[ 2 j 
The always constraints in G'Auth formalize the dashed lines linking task 1 1 of 
component C\ to tasks t 2 and tA of component C 23 4. The component obtained by 
gluing Ci and C 23 4 together with G (in symbols, C\ © G C 234 ) is such that 

— its set of transitions contains all transitions in Xr 23 4 plus the transition in 
Tr 1 modified to take into account the inter execution constraint in Gec, i-e. 

tl(u) : pOi A =>d tl A a t \(u) - 5 > p 0 1 ,pli,d tl ,h t i(u) := F, T, T, T||p 0 234 := T 

ensuring that when the token is put in pl\ it is also put in p0 23 4 (in this way, 
we can specify how the control flow is transferred from C\ to C 23 4); 

— its set of always constraints contains all the constraints in B\ and P 23 4 plus 
those in GAuth so that the SoD constraints between task fl in C\ and tasks 
t2 and M in C 23 4 are added; 

— if its interface is ( A , P l , P°, H°, C l ), then P l := -fall} since p 0 23 4 occurs in 
Gec, P° ■= {^^ 234 } since pli occurs in Gec, an d C l := 0 since both c\ 2 and 
c\ 4 occur in GAuth- 

Notice that C\ © G C234 can be combined with C5 so as to form a component 
corresponding to the TRW in Figure [T] This is possible by considering the 
following set G = G' EC UGfa th of gluing assertions where G' EC := -fa 7 23 4 pO^} 
and G(^ uth := {\/u.c] 5 (u) 4 => ~<ht2{u) A-i/i* 3 (u)}. The inter execution constraint in 
G ec corresponds to the dashed arrow connecting p 7 in component C 23 4 fa 7 23 4 ) to 
pO in component C5 faOs) in Figure [ 2 ] The always constraint in GAuth formalizes 
the dashed lines linking task f 5 of C5 with tasks t 2 and t 3 of C 23 4. □ 

We now illustrate the computation of the wlp with respect to the transitions 
of a composed component by means of an example. 


Example 5 . Let us consider (C\ ®g C234) ®g' C5 of Example [ 4 ] and the predicates 

K x := ~np0 1 A d a I<5 ■= ^p0 5 A pl 5 A d t5 
A '234 : = f\ _I P*234 A d t 2 A d t 3 A d t 4 A d S234 A dj 234 

i—0,... ,6 

whose conjunction K characterizes the final states of TRW, i.e. those situations in 
which all tasks have been executed and there is just one token in place pl 5 (notice 
that K234 does not mention p7234 whose value is implied by K$ and the inter 
execution constraints p7234 •£=> pOs and similarly K\ does not mention pli whose 
value is implied by RT234 and the inter execution constraint in pli •£=> PO234). 

Now we compute wlp(f 5 , B, K) where B is the union of Bi, B234, B 5 , GAuth, 
and G^ uth given in Example [ 3 ] by using ([ 3 ]) : 

R'i A R'234 A (p 0 5 A ~^d t 5 A at 5 (w) A ^h t 2 (u) A . ( 4 ) 

Notice how A'i and K234 have not been modified since the parallel updates of t 5 
do not mention any of the state variables in C\ and C234 but only those of C5, 
namely pOs and dt5 ■ 

To illustrate how the computation of wlp takes into account the transfer of 
the control flow from one component to another, let us compute the wlp of @ 
with respect to transition j in component C234. According to the definition of 
composition of components, transition j’234 becomes 


J 234 ; P 4 234 A p5 23 4 A p6 23 4 A ~^dj 23i 

-A p4234,p5234,p6234,p7234,dj 234 := F, F, F, T, T\ |p0 5 :=T. 


Notice the added assignment pOs := T to take into account the inter execution 
constraint in G' EC (see Example | 4 | ensuring that when the token is put in p 7 234, 
it is also put in PO5. By using ([ 3 f( we have that wlp(j 2 34 , B , Q) is 


ATi A 


WO 234 A ^pl234 A ^p2 2 34A 
W?3 2 34 A p4 23 4 a p5 23 4 a P 6234 A 
-'dt 2 A -id t 3 A ->d t 4 A ^d S234 A dj 234 


f ->d t 5 A a t5 (w)A \ 
\-'h t2 (u) A -^h t3 (u) J 


( 5 ) 


Notice how K\ is left unmodified since it describes the state of component C\ 
and no gluing assertions involve state variables of C\ and those in the update of 
j'234, R234 instead is modified substantially (see the predicate in square brackets) 
since j’234 is a transition of component C234, while the remaining part of 0 is 
almost identical to the formula between parentheses in Q except for the deletion 
of pOs because of the additional assignment pOs := T in J234, introduced to take 
into account the inter execution constraint in G^ uth . 

An alternative way of computing wlp(j2 34 ,-B, Q) is the following. Observe 
that the value of p7234 is fixed to T because of the inter execution constraint pOs 
p7234 in GAuth and the fact that Q implies that PO5 is T. Thus, we can consider 
the predicate A'234 Ap7234 and then compute wlp(j234, B234, K234^p7234) which is 
the predicate in square brackets of (J 5 |. By taking the conjunction of this formula 




with Ki and the predicate obtained by deleting pOs from wlp(f5, B 5 U GAuth, K 5 ) 
in which we delete p0 5 (because d4 ) implies that p0 5 is T) thereby obtaining the 
predicate between parentheses in (2]), we derive © as before. □ 

The last paragraph of the example suggests a modular approach to computing 
wlp’s. It is indeed possible to generalize the process described above and derive 
a modularity result for computing the wlp of a complex component by using 
the wlp’s of its components by taking into account the gluing assertions. We do 
not do this here because it is not central to the applications of the notion of 
component discussed in Section [ 4 ] below. 

Theorem 1. Let ( Sk,Intk ) be a symbolic security-sensitive component for k = 
1 , 2 , 3 , Gi,2 be a set of gluing assertions over Inti and, Int 2 , and G 2,3 be a set of 
gluing assertions over Int 2 and Int 3 . Then, 

Commutativity: (Si, Inti) ©g 1j2 ( S 2 ,Int 2 ) = (S 2 , Int 2 ) ®Gi, 2 (Si, Inti) and 
Associativity: ((Si, Inti)®c(S2, Int 2 ))®G(S3 , Int$) = (Si, Inti)®G((S 2 , Int 2 )®G 
(S3, Ints)) for G = G 1i2 U G 2 , 3 . 

The proof is straightforward and based on the commutativity and associativity 
of set union. Notice that the associativity property above is expressed by taking 
into account the union of the gluing assertions over the interfaces of the reusable 
systems being combined. 

Example 6. Recall the components of Example [ 4 ] Because of Theorem [l] we have 
that the TRW can be expressed as Ci ©g" C234 ©g" C5 for G" = G U G' where 
G,G' have been defined in Example |2J 

Notice that, despite the commutativity of the operator ©, the task in Ci will 
always be executed before all tasks in components C234 and C5 because of the 
gluing assertions in G" . Thus, the component C234 ©G" Ci ©G" C 5 obtained by 
considering the components in a different order is equivalent to TRW. □ 

Appendix |A] shows how standard composition patterns available in the literature 
for workflows can be expressed by using the notion of components and the 
composition operator © introduced above. 

4 Applications 

We present two applications of security-sensitive components and their modular 
combination which are made possible by the same modularity result about the 
synthesis of run-time monitors for the WSP. 

In we have shown how to automatically derive a monitor capable of 
solving the run-time version of the Workflow Satisfiability Problem (WSP) [ 5 j 
of a security-sensitive transition system. As already discussed in the paragraph 
“Semantics of a security-sensitive component” in Section [ 2 ] the notion of 
security-sensitive transition system introduced here and that in [2] are equivalent. 

In particular, given a security-sensitive transition system ((P, D, A , H , G), Tr, B) 



we can derive an equivalent security-sensitive transition system of the form 
((P,D,A',H,<D),{[[tr]) B \ tr £ B},0), which is precisely a security-sensitive transi¬ 
tion system of [3], where A’ contains the variables in A and those in G which 
are not mentioned in B. Let 1ZA4 be the procedure which takes as input a 
security-sensitive transition system S = ((P,D,A,H,C),Tr,B), applies the 
transformation above, and then the procedure for the synthesis of run-time 
monitors described in [3], which returns a Datalog [4] program 1ZM(S) defining 
a predicate can-do(u,t) such that user u can execute task t and the workflow 
can successfully terminate iff can-do (u , t) is a logical consequence (in the sense of 
Datalog) of TZM(S) UPU H (in symbols 1ZM(S),'P,'H \= can-do(u,t)), where 
V is a Datalog program defining the meaning of the predicates in A (i.e. the 
authorization policy) and 'H is a set of history facts of the form ht(u ), recording 
the fact that user u has executed task 

We now show how to reuse TZA4 for the modular construction of run-time 
monitors for the WSP, i.e. we build a monitor for a composite component by 
combining those for their constituent components. Let G = Gec U GAuth be a 
set of gluing assertions where Gec is a set of inter execution constraints and 
GAuth a set of always constraints over an interface (A,P l ,P°, H°,C l ), then 
(G) := (Gec) U (G Au th), where (G E c) := {p l P°\p l « P° £ G E c} and 
(GAuth) := {c l (u) <— hst 1 (u)\\/u.c l (u) <f=> hst l {u ) £ GAuth}- Intuitively, the shape 
of the Datalog clauses in (Gec) models how the execution flow is transferred 
from a component (that with an output place) to the other (that with an input 
place). 

Theorem 2. Let ( S k ,Int k ) be a symbolic security-sensitive component, Sk = 
(( P kl D k ,A k ,H k ,C k ), Tr k ,B k ), H k is a set of (history) facts over H k , and V k 
a Datalog program (for the authorization policy) over A k , for k = 1,2. If G is 
a set of gluing assertions over Inti and Int 2 , then TZA / l(S),'Hi,'H 2 ,Pi,P 2 |= 
can_do(u,t) iff TZJ\A(Si),'Hi,Vi, (G) ,PM(S 2 ),'h 2 ,P 2 1 = can-do(u,t) , where 
( S,Int ) = (Si, Inti) ©g ( S 2 ,Int 2 )• 

The idea underlying the proof of this theorem is that the monitors for the 
components are computed by considering any possible values for the variables 
in their interfaces. The additional constraints in the gluing assertions simply 
consider a sub-set of all these values by specifying how the execution flow goes 
from one component to the other and how the authorization constraints across 
components further constrain the possible executions of a component depending 
on which users have executed certain tasks in the other. 

As anticipated above, Theorem [2] paves the way to two applications which 
are discussed more in detail in the following. 

Scalability of the Synthesis of Run-Time Monitors. It is possible to de¬ 
compose large workflows into smaller components by using pre-existing techniques 
(see, e.g., EH), generate monitors for each module and glue them, allowing us to 
solve the WSP for very large workflows, which would be otherwise intractable 


2 There is an established line of research (see, e.g., [TO]) that has used (variants of) 
Datalog to express authorization policies. 




Fig. 3. Time taken to synthesize a monitor varying with the number of tasks 


due to state space explosion as shown in [3]. The main obstacle to the monitor 
synthesis is the state space explosion caused by the need of computing all the 
possible interleavings of task executions and the execution of these tasks by the 
users. Theorem [2] allows for splitting a large security-sensitive workflow into 
smaller components, allowing one to synthesize the monitors for such components 
with smaller state spaces and then glue them together in order to build the 
monitor for the composed component. 

To show the practical scalability of this approach, we have performed a set 
of experiments with the random workflow generator from [3], which is capable 
of generating random security-sensitive workflows with an arbitrary number of 
tasks and composing them sequentially. For the experiments, we have generated 
components with a fixed size of 5 tasks and a varying number of constraints. The 
number of constraints is specified as a percentage (5%, 10% and 20%) of the 
number of tasks in each component for intra-component constraints and as a 
percentage of the total number of tasks for inter-component constraints. Thus, in 
the configurations 5% and 10% there are no intra-component constraints, while 
in the configuration 20% there is one for each component; for a workflow with 
100 tasks, there are 5 inter-component constraints in the configuration 5%, 10 in 
the configuration 10% and 20 in the configuration 20%. The experiments have 
been conducted on a MacBook Air 2014 with a 1.3GHz dual-core Intel Core i5 
processor and 8GB of RAM running MAC OS X 10.10.2. The results are shown 
in Figure [3j in which the x-axis contains the total number of tasks in a workflow 
divided by 10 (the total number of components is the number in the x axis times 
2 ) and the y-axis shows the total time in seconds taken by the monitor synthesis 
procedure TIM of [3]. Each data point is taken as the average of running TIM 5 
times for each configuration. Figure [3] suggests a linear (instead of the expected 
exponential!) behavior with respect to the number of tasks on this set of synthetic 
benchmarks. 

A Tool for the Design and Reuse of Components and Monitors. Recent 
practices in business process management have emphasized the use of business 







Repository (BPMN + Monitor) 



Fig. 4. Architecture of a business process design tool integrated with a repository 
of models and monitors 


process repositories [22] in order to promote process reuse and more quickly ad¬ 
dress the rapidly evolving requirements on business process. Theorem [2] supports 
not only the creation of repositories containing reusable business processes in 
the form of security-sensitive workflows but also associating with them run-time 
monitors that can be modularly combined to create more complex monitors for 
composed components. These are important features in the context of industrial 
applications of business processes, as they support reuse of existing technologies 
(editors and repositories of business processes) and augment them by monitor 
synthesis capabilities that make the synthesis automatic, scalable (as shown by 
the experiments above), and transparent to the final user (the procedure TZA4 is 
fully automated). Figure [4] outlines the high-level architecture of a tool exploiting 
the ideas discussed here. Rectangles represent components, ovals represent stor¬ 
age systems, R-labeled links represent request/response communication channels 
between components (where the direction of the arrow states the direction of the 
request), and arrows represent access to storages. The BPM (Business Process 
Management) component represents any existing solution including a modeling 
environment for BPMN-based business processes. The Process Composer sub¬ 
component is the modeling environment offering a BPMN editor. Examples of 
BPM systems are IBM Business Process Manage^ SAP Netweaver BPIVj/] and 
Signavio Process Editoij^] The Monitor Synthesizer component implements the 
procedure 1ZM described above to compute (modular) monitors for workflow 
components and their composition modeled in the process composer. The Repos¬ 
itory component represents a storage system for workflow models together with 
the monitor synthesized by the (modular) monitor synthesizer. Note that such 
repository may be part of the BPM solution (as in, e.g., IBM Business Process 
Manager) or remotely located (e.g., Apromore [15j). The modeler interacts with 
the process composer with a request/response relation. The same relation ex¬ 
ists between the process composer and the monitor synthesizer to request the 
synthesis of a run-time monitor for the BPMN model under specification. The 
process composer can store/retrieve BPMN models together with the synthesized 
monitors to/from the repository. 

Example 7. Let us recall the situation in Example [2] The tool in Figure [I] 
allows us to re-use components C\ and C 5 in both the specification of TRW and 

3 http://www-03.ibm.com/software/products/en/business-process-manager-family 

4 http://scn.sap.com/docs/DOC-27944 

5 http://www.signavio.com/products/process-editor/ 











MDW as shown in Figure [2] Additionally, the capability of storing automatically 
synthesized run-time monitors in the repository associated to the components 
permits their re-use in different business processes thanks to the modularity 
result in Theorem [2] □ 

The business process modeling (process composer in Figure [4]) and repository 
components in the proposed architecture are also part of common reference archi¬ 
tectures, e.g., j21j . The monitor synthesizer and the extension of the repository 
to store monitors are unique contributions of this paper. Whenever a business 
modeler uses the process composer, he/she can import models with their associ¬ 
ated monitors from the repository, combine the models with new or pre-existing 
models and export the resulting complex component back to the repository, 
storing the process together with its monitor. Notice that the monitor synthesis 
of the various components can be done, when necessary, while the editing is 
progressing, thereby optimizing the waiting time for the monitor. 

So far, we have implemented the (modular) monitor synthesizer as a command¬ 
line tool and not yet integrated it with a modeling environment. We intend to 
do so using the extensible Signavio Core Componentt]^] editor and a repository 
structure like Apromore [15) . which is already integrated with the editor and 
supports BPMN 2.0 models for processes. The repository must be extended 
to store parametric Datalog monitors associated with BPMN. We believe that, 
since all the steps are automated, the graphical integration will provide a very 
simple to use, push-button approach for modelers to modularly and efficiently 
derive precise run-time monitors for business processes that can be later securely 
deployed. 

5 Discussion 

We have described and formalized a modular approach for the synthesis of 
run-time monitors for reusable security-sensitive workflows. We have shown the 
scalability of modular monitor synthesis by means of experiments. We have 
also discussed the initial implementation of a tool integrating an editor with a 
repository of business processes extended with the capability of storing associated 
run-time monitors so that the modular synthesis of monitors can be exploited in 
business re-use. 

Reuse in Business Process Management has been an intense topic of research 
and industrial application; see, e.g., [&16j . Several works in the field of Petri net 
have investigated modularity; see, e.g., .12]. To the best of our knowledge, none 
of the works in these contexts addresses security issues as we do here. The most 
closely related work is [3], which is extended here with the notion of modularity. 

As future work, we intend to fully implement the architecture in Figure [4] by 
using available repositories, such as Apromore [T5]. We also plan to perform ex¬ 
tensive experiements concerning process reuse on the business processes available 
in the repositories. 

b https://code.google.com/p/signavio-core-components/ 
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Fig. 5. Sequential (left), simultaneous (center) and alternative (left) composition 


A Composition patterns 

We show how the basic control patterns in workflow management (see, e.g., E0) 
can be expressed by the gluing operator ® introduced above. We consider 
sequential (when n processes are executed one after the other), parallel (when n 
processes are executed in parallel), and alternative composition (when only one out 
of n processes is executed). For lack of space, we do not consider other composition 
patterns (such as the hierarchical one, when a task is refined to a complex process) 
which can also be expressed in our approach by using a bit of ingenuity. To simplify 
the technical development below, we describe each composition pattern using 
two components (Si, Inti) and ( S 2 ,Int 2 ); the generalization to n components 
is straightforward. Additionally, again for the sake of simplicity, assume that 
Pj = {pj} and P° = {p°} in Intj = (Aj, P},P °, H °, Gj) for j = 1,2, i.e. there is 
just one input and just one output place in both components. (Notice that this 
assumption is satisfied when considering workflow nets—see, e.g., [TS]— which 
are a particular class of Petri nets frequently used for modeling workflows.) 
Sequential composition. Let us consider the situation in which the process specified 
by component Si must be executed before the process executed by component 
5*2■ To model this with the gluing operator, it is sufficient to consider a set G = 
Gec U GAuth of gluing assertions over Inti and Inf 2 such that Gec = {p\ ^ Pi}- 
Notice that (Si, Inti) ©g (£ 2 , Int- 2 ) = (S 2 ,Int 2 ) ©g (Si, Inti) by Theorem [I] but 
because the gluing assertion in Gec is P 2 p°, and not P 2 ^ p\, the process 
specified by component (Si, Inti) will always be executed before that specified 
by (S 2 ,Int 2 ) when considering their composition. 

Parallel composition. Let us consider the situation in which the processes specified 
by components Si and S 2 must be executed in parallel. To model this with the 
gluing operator, we need to preliminarily introduce two other components, each 
containing a single transition, one for splitting and one for joining the execution 
flow. Formally, we define C* = ((((P*, P*, 0,0,0), TV*, 0), (0, P*, P*°, 0,0)), Int*) , 
Pas = {pOas ? P^-as ? D as = {^as}i Paj = {.Q^aj > QXajt Q^ajPaj = {^aj } 5 

Tr as := {pO as A -» d as ->• pO as ,pl as ,p2 s , d as := P,T,T,T} 

Praj •— \_Q^CLj ^ A ~ 1 d a j y qOaj , qlaj > <&aj 5 d a j •— P?P •> 














and Inf* = (0, P*% P°, 0, 0) with P^ s = {pO QS }, P“ s = {pl os ,p 2 os }, and Ph = 
{gO aj , glaj}, Paj = { ( ?2 aj }, where * stands for a(nd) s(plit) or a(nd) j(oin). At this 
point, it is sufficient to consider a set G = G E c U GAuth of gluing assertions over 
Inti, hit 2 , Int as , and Int a j (recall the associativity of the gluing operator stated 
in Theorem [l]) such that G E c = {pl as ^ p\,p2 as & p\,p\ qO a j,P% O ql a j}- 
Alternative composition. Similarly to parallel composition, we need to intro¬ 
duce also for this pattern two other components, each containing two non- 
deterministic transitions to route the execution flow in one of the two com¬ 
ponents (Si, Inti) or (S 2 ,Int 2 ) instead of both as above. Formally, we define 
G* = ((((P*,D*,0,0,0), IV*, 0), (0,P*,P*,0,0)),Int*) , P os = { P 0 os ,pl os ,p2 os }, 

Dos — { d os } ■ Poj — { pbj ■ l1 1 ojj • < 7 2 aj } - D 0 j — { d Q j } ■ 


(pOosA^d os -P p 0 os ,pl os ,p 2 s ,d os := F, T, F, T, 1 
\ p0 os A ~^d os ~P p 0 os ,pl os , p2 s , d os :=F,F,T,T J 

f qO oj A ‘d 0 j t q0 o j , q2 0 j , d Q j := F , T, T, 1 
\ I 1 °j I' 'd 0 j t ql 0 j, q2 a j , d Q j •— P, T, T J 


and Inf* = (0, P*, P*°, 0, 0) with P l os = {p0 os }, P° s = {pl os ,p2 os }, and P l oj = 
{qt) 0 j,ql 0 j}, P°j = {q2 0 j}, where * stands for o(r) s(plit) or o(r) j(oin). At this 
point, it is sufficient to consider a set G = G E c U GAuth of gluing assertions over 
Inti, Inf 2, Int os, and Int Q j (recall the associativity of the gluing operator stated 
in Theorem [l]) such that G E c = {pl os p\ , p 2 os p 2 ,p° •£=> qQ 0 j,P2 ^ q^oj}- 


